UI unit Tests

12 tests  ±0   12 ✅ ±0   0s ⏱️ ±0s
 4 suites ±0    0 💤 ±0 
 1 files   ±0    0 ❌ ±0 

Results for commit 49d98c4. ± Comparison against base commit 30c8d5a.

♻️ This comment has been updated with latest results.

C# Unit Tests

104 tests  ±0   104 ✅ ±0   5s ⏱️ ±0s
 16 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit 49d98c4. ± Comparison against base commit 30c8d5a.

♻️ This comment has been updated with latest results.

One issue that came up when I tested it, but shouldn't arise in production: the elawa project, at the time I tested this, had no members and so there was nobody to send the email to, yet the notification falsely told the user that the project managers had been emailed. However, in production we have a rule that projects without managers aren't allowed, so I think it's safe to ignore that situation.

if it's an exceptional case then lets throw an exception for that, the UX isn't great but it's better than a false positive I think, and then we don't have to properly handle that case which should never happen.

looks good, just a minor change of throwing an exception from the backend if there's no managers to email

Done in commit 3401e2e, but I'm getting a Typescript error. Although I declared that the AskToJoinProject mutation can throw the new ProjectHasNoManagers exception, that's somehow not getting into the generated GQL types: when I run task api:generate-gql-schema, I see the ProjectHasNoManagers error in the schema but the AskToJoinProjectMutation type isn't updated with the new list of possible errors.

So this will fail to build (update: yes, it fails), but I'm pushing it anyway because it should be working and I need a bit of help figuring out why the GraphQL type generation is failing.

the issue was that joinResult.error did not have a __typename as it wasn't in the gql query, and byType only accepts the type name using some generic hoops to only accept valid values, in this case since it wasn't selected it was never. I wish we could instruct TS to show a custom error when trying to assign to a never type, but I don't think that's possible.

Okay, so it looks like the only thing remaining is to put an approving review on this and I can get it merged. (I could check the "bypass rules" checkbox, but there's no reason to skip steps in this case).